The Java language is well known in the art, and a brief review suffices for the purposes of the present invention. Java is an effective object-oriented programming language that shares many syntactical characteristics of the C and C++ languages. The popularity of the language emanates from a number of features, two of the principal (and related) ones are first that the language is portable, and, second, it is architecturally neutral. For example, some of the standardized features that make Java portable are that:
Java provides the same Application Programmer Interface (API) for all systems; PA0 Java uses the 16-bit Unicode character set that can be used to encode all the symbols of virtually all the world's languages; and PA0 Java supports numerical and operand evaluation standards found in most other programming languages. PA0 1. A relatively minor programming change in a product, such as changing the data type returned from a Java method, requires every derived class which implements the method and every other class which invokes the modified method to be manually updated to reflect the change. Other changes are potentially much more destructive; for example, changing the name of the method may cause a conflict if a method further down the inheritance tree has the same name. PA0 2. It is routine for large software applications to be customized (e.g. for specific customers or sites). In prior art systems, customization renders large software applications nearly impossible to maintain. For example, consider a base software application that has been installed for many different customers. Each of these customers will usually change parts of the base application to accommodate their specific needs. The changes are accomplished by making modifications to parts of the program, or in object oriented programming, by modifying the classes of objects in the application. If the application vendor subsequently modifies these classes, and the customer wishes to upgrade the application to incorporate those modifications, then the customer must determine what customizations were made to the original classes and similarly customize the updated classes. (Alternatively, if the vendor's modifications are minor, it may be possible to isolate those changes and apply them to the older but customized version of the classes.) In a large customized application, this work is substantial enough that many customers continue to use out-of-date versions indefinitely. The effort that is required to upgrade a customized application is often larger than the original customization effort. Compounding the cost of upgrading is the potential for introducing new problems into a software application that is already in use. PA0 3. Localization is an additional requirement for many software applications and involves tailoring a software application to the language, input methods, and standards of a specific locale. This may include supporting different units of measurement and financial currencies, fulfilling legal requirements, and displaying dates, times, and currencies in the expected formats. These changes to an application provide challenges similar to those resulting from application customization; however, localization multiplies, rather than simply adding to, the number of potential application configurations, since a localized application can be customized or vice versa. PA0 Identity is used to exactly specify (to name) a class of objects, for example "button;" PA0 Behavior consists of the operations that a class of objects can perform, for example how a "button" reacts when pressed; PA0 State describes the current attributes of an object, for example the text displayed on a "button;" and PA0 Containment refers to a relationship between multiple objects where one object is contained within another, for example, the "button" could be contained within a "window." PA0 1. If the aforementioned "button" on the "window" is itself a class (which is to say that this particular "button" on this particular "window" has its own class identity), it cannot define its position, since the position was declared in the "button" super class from which this particular "button" inherits. PA0 2. If the aforementioned "button" on the "window" is simply an instance of a generic "button" class (as in the most common prior art systems), then inheritance does not apply, since this "button" is not in and of itself a class, and therefore does not inherit. PA0 1. The state must also be induced from the behavior. PA0 2. As part of the program source code, these instructions are a source of entropy, making the program more error prone, more difficult to maintain, and less capable of change. PA0 3. The state is not inherited. PA0 1. This particular "button" would contain the instructions required to fully configure its state as designed. This approach fails to provide inheritance because changes to classes from which this particular "button" derives would not be reflected in the instructions that configure the state of this "button." PA0 2. This particular "button" would first execute the state configuration instructions of its super class (the class which it inherits from) and would then configure only the portion of its state that differs from the state of its super class. This approach is limited because of its recursive nature (i.e. the super class itself may have a super class); each class must redo the state configuration of its super class that differs from its own. As an example, consider the position portion of the "button" state. If the position of the super class is different from the position of this particular "button," then the "button" is positioned by the super class and then re-positioned by this "button" class. Since more than two levels of inheritance are common, the "button" could literally jump around the screen while it is being created. Although humorous as a visual example, the results would be less funny in a financial application.
Architectural neutrality is ensured by standardization on the Java Virtual Machine (JVM). This is a critical and very attractive feature of Java. When Java source code is compiled the usual output is an intermediate code called Java Byte Code UBC); this code is not directly executable. Since JBC is a platform independent standard, there is a need for a platform-specific interpreter or compiler to provide the binary code that actually executes on a specific machine.
The above features of the JVM emanate from its standardized formation of object classes that are platform independent and, via the platform specific interpreter, made compatible and operational with the particular systems. Two standards for such object classes have emerged as the most popular--the JavaBean and CORBA (Common Object Request Broker Architecture) objects. JavaBeans often are graphical controls used in (but not limited to) the construction of a Graphical User Interface (GUI). CORBA objects are capable of bridging language, machine, environment and other such boundaries. Java is described in "The Java Language Specification," Sun Microsystems Inc., JavaBeans are described in the "Java Beans API specification," version 1.00, Sun Microsystems Inc., and CORBA is described in the "Object Management Architecture Guide," 3rd edition, from the Object Management Group, Inc., all of which are incorporated herein by reference.
The widespread adoption of Java and Java compatible software and systems has made it desirable to provide software tools for applications developers that are compatible with the installed systems. The development, deployment and maintenance of large and complex software applications, such as line-of-business and packaged applications, introduce particular problems that are not typically encountered in small-scale projects. Large projects become increasingly difficult, time consuming and error prone, and inefficiencies and limitations of the technologies and derived software tools become more pronounced and noticeable. Consider the following examples:
With respect to this invention, the following four implemented concepts are important. The four are: Identity, behavior, state and containment which are defined and discussed below and are well known terms of art:
In practice, well known in the art, the above items may typically be implemented on a computer display. A "window" is typically a framed area, and a "button" appears as a smaller framed area within the window. The appearance is that of a physical window containing a physical button, where the button can be "pressed" or activated by "clicking" on it.
Inheritance is a central feature of object-oriented programming in general and the Java language in specific. In Java, heredity is substantially limited to the identity and behavior of a class. The Java language lacks the notion of inheritance of state and containment. The state of a Java object is typically held by class variables, which the Java language calls "fields." The value of a field can be specified only in the class that declares the field. Java programs commonly use containment of objects, but not inheritance via the containment.
Object-oriented programs built using the Java language are thus limited by the lack of support for inheritance of state and containment as illustrated below.
Most of the technical terms used herein are defined by Dr. Grady Booch in his book, "Object-Oriented Analysis and Design," 2ed, published by The Benjamin/Cummings Publishing Co., Inc. in 1994, which book is incorporated herein by reference.
Illustrating the inheritance issues with state and continuing with the "button" example, it is expected a "button" would include its display position as part of its state. This implies that the "button" class, or a class that it inherits from, declares position as part of its state. The act of positioning a "button" on a "window" defines the position portion of the state of the "button." Using this example, the limitations of prior art systems become evident:
In the two examples above, prior art systems represent state by constructing behavior. In other words, state is implemented by producing Java language instructions that modify the object instance after it is instantiated; therefore:
Continuing with this example, to appreciate the problem with inheritance, consider that the resulting state of this particular "button" is the culmination of its inherited state plus the changes to that state which were made on this particular "button" itself. There are two main ways which prior art systems have implemented this:
Similar problems exist with containment. Generally, in the prior art, contained objects are not themselves classes and therefore do not have a class identity, an inherited state, customized behavior, or recursively containment elements capable of these same features. Furthermore, in order to support the inheritance of state, behavior, and containment of all classes, it is essential that, when a containing class is inherited, that the contained classes (and so on) be inherited as well. Since Java does not support containment, it obviously does not provide inheritance of contained objects.
FIGS. 1A and 1B illustrate general prior art principles that are characteristic of Java inheritance. Several phrases exist that describe inheritance: if a descendant class "D" inherits from an ancestor class "C," then it is said that "D is a C," that "D extends C," that "D inherits from C," that "D derives from C," and that "C is a super class of D." FIG. 1A shows a simple class inheritance hierarchy which exists in Java: a Button 2 "is a" 4 Component 6, which "is a" 8 Object 10. Furthermore, a Button 2 "is a" 4 and 8 Object 10, but this relationship is qualified as indirect, for example "Button indirectly inherits from Object" or simply "Button is a descendent of Object." (For reference, the fully qualified Java classes shown in FIG. 1A are java.lang.Object 10, java.awt.Component 6, and java.awt.Button 2.)
FIG. 1B shows a larger class inheritance hierarchy that exists in Java, incorporating the hierarchy from FIG. 1A. In this diagram, as in FIG. 1A, Component 14 "is a" Object 12, and Button 16 "is a" Component 14. Additionally, File 24 "is a" Object 12, Checkbox 18 "is a" Component 14, Container 20 "is a" Component 14, and Window 22 "is a" Container 20. The hierarchy is not limited in depth, and at any depth there can exist any number of classes. The design of the inheritance system mandates that each fully qualified class name be unique and that all classes inherit directly or indirectly from Object 12. (For reference, the fully qualified Java classes shown in FIG. 1B are java.lang.Object 12, java.awt.Component 14, java.awt.Button 16, java.awt.Checkbox 18, java.awt.Container 20, java.awt.Window 22, and java.io.File 24.)
In contrast to the "is a" of FIGS. 1A and 1B, FIGS. 2A and 2B pertain to containment. FIG. 2A illustrates a common use of containment, which is the containment of graphical objects. (The contained graphical objects are typically referred to as "controls" or "components." The containing graphical object is often a "window," "form," "pane," "site," or just "container.") Although the Java implementations of containment in the prior art vary widely, the concept of a container/containee relationship is extensively used for constructing complex objects, such as the object in FIG. 2A. In this figure, the Message 26 contains Text 28 and OK 30 and Cancel 32 buttons.
FIG. 2B extends the example slightly from FIG. 2A by adding recursive, or "nested," containment. Again, containment is a hierarchy in which a container can contain objects that are themselves containers. In FIG. 2B, Choices 38 is contained by Message 34 and Choices 38 in turn contains Shutdown 40, Restart 42, and Logoff 44. The expected visual representation of Choices 38 and the graphical controls that it contains would be a group of items, of which one and only one can be selected.
It is an object of the present invention to provide a data structure that fully describes the identity, state, behavior, and containment information related to the design of a software component. A related object is that software components contained therein be able to utilize the same data structure (a nested instance thereof) to describe their identity, state, behavior, and containment information.
It is another object of the present invention that the data structure can support the feature of inheritance with respect to the identity, state, behavior, and containment information. A related object is that software component information contained therein is inherited when the containing software component information is inherited; in other words, the inheritance applies to the entire containment hierarchy.
It is another object of the present invention that the data structure can be implemented for and can be fully compatible with the JVM, allowing use at any and all particular installations.
It is yet another object of the present invention that the data structure contains sufficient and unambiguous information in order to create Java classes from that information. A related object is that the resulting classes be Java software components capable of being assembled into or used in software applications and tools.
Still another object of the present invention is that the data structure enables the computing system to do the bulk of the work when updates or other changes are made to an instance of the data structure. Most significantly, this applies to the feature of inheritance, in which a change to the design of a software component impacts those software components that inherit from it. Additionally, this applies to software customization and localization, which produce component modifications for particular customers and locales. A related object is to enable the computing system to automatically detect and fix conflicts and redundancies caused by such changes.
Yet another object of the present invention is to provide a component data structure derived from a component data structure, wherein the derived component data structure elements can be reconstructed even if the base component data structure elements have been altered or removed. A related object of the present invention is to provide a "tag" associating the elements of a derived component data structure to the corresponding elements in the base component data structure.
Still another object of the present invention is to provide a delta component data structure wherein the elements of the delta component data structure are the differences between the elements of the base and the elements of the derived component data structures.